The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Inter-Process Communication (IPC) is used by processes to communicate with each other while running on the same computer. It is an important part in the operating system as synchronizing and data exchange occurs frequently throughout the system operation. However, without protection, as in conventional operating systems, IPC can be used for attacks. Typical examples include sending malicious payload to a privileged process or overloading the IPC to cause denial of service attacks. System V IPC objects includes message queue, semaphore set and share memory segment. These objects are identified by a unique identifier. To access an IPC object, this ID is the only thing needed. Even though a key is needed to obtain the ID, there are scenarios in which other processes can connect to the IPC object without the key. Standard Discretionary Access control (DAC) can be enforced on the IPC objects. However, DAC does not provide sufficient protection. In summary, secure IPC is needed within the OS.
Before launching into discussion of the present teachings, one security mechanism in particular deserves some discussion. Umbrella is a security mechanism for Linux implementing Process-Based Access Control (PBAC). The PBAC scheme moves the responsibility of restricting capabilities of programs from the system administrators to the developers. The reasoning behind this, is that the developers have a deeper knowledge on which restrictions are necessary for their own software. A restriction on a subject, means that it have access to all objects except those objects which is in the restriction list. In difference to other security schemes, PBAC only defines one global security policy.
Global Policy 1. Given that p1 and p2 are nodes in the process tree P and p1 has the restriction set r1 and p2 has the restriction set r2. r1 and r2 being subsets of R which is the set of all possible restrictions. If p1 is a descendant of p2 then r1 is a superset of r2.
This policy ensures that processes are at least as restricted as their parent, regardless of their ownership. Thereby restrictions respect the partial order in the process tree. Umbrella extends this policy by providing a restricted fork system call and signed binaries. The restricted fork system call allows the software developer to apply further restrictions on child processes. The signed binaries enables the developer to embed restrictions in the binary of a program. Furthermore, the signed binaries allows the system administrator to verify the origin and integrity of a program, and to apply restrictions accordingly.
Currently Umbrella only includes restrictions for a limited set of IPC methods, i.e. files, signals, sockets, and named pipes. It is not possible to restrict programs from using the System V IPC methods, that is shared memory, semaphores, and message queues, using Umbrella. As the following example shows, this limitation has some problems, and in the worst case it will actually enable programs to circumvent the restrictions enforced by Umbrella.
Assume, for example, that an e-mail client is using a System V IPC method to communicate with the address book. Whether message queues or shared memory is used is not that important, however, assume that message queues are used in this example. Also, assume the e-mail client and the address book are running as the same user, then the least possible standard Unix permissions for the IPC will be 0600. The attachment is still restricted from using the network and from accessing /boot, /etc, and ˜/.abook on the local file system. However, since the attachment is running as the same user as both the e-mail client and the address book, and no restrictions are enforced on message queues by Umbrella, it will have read/write permissions on the IPC.
The aforementioned permissions enable the attachment to mount at least four attacks: (1) eavesdropping: the attachment will be able to read all, or at least a large part of, the messages exchanged between the e-mail client and the address book; hence, the attachment will be able to see data it was not supposed to (remember the attachment was restricted from ˜/.abook.); (2) substitution: the attachment will be able to alter messages exchanged between the e-mail client and the address book; (3) denial of service: the attachment will be able to exchange all messages with empty messages, and thus, effectively creating a Denial of Service attack; and (4) stack smashing: assuming either the e-mail client or the address book has a stack smashing vulnerability, the attachment will be able to execute arbitrary code with the privileges of the e-mail client or the address book, respectively; in this case it allows the attachment to escalate its privileges and circumvent the Umbrella restrictions on the network and ˜/.abook; however, it will still not be able to access /boot nor /etc.
It should be readily understood that the eavesdropping, substitution, and Denial of Service attacks are very similar, and they are in fact all man-in-the-middle attacks.